High-level emulation (HLE) is an approach for construction of emulators, especially for video game consoles, which attempts to simulate the response of the system rather than accurately recreating its internal design.
Instead of trying to accurately create or recreate the hardware gate by gate, in HLE a software platform is created on which the emulated code can be run in a host computer having different hardware and a different instruction set. The effort focuses on recreating the appropriate functionality provided by the system emulated. Thus, the emphasis is shifted from the most efficient method of processing data to getting the same (or comparable) results as if the native platform was used. By contrast, the traditional way of emulating is termed Low-level emulation, or LLE which is used to develop new computer hardware and execute legacy binary code.
The term HLE originates from UltraHLE, the first emulator for the Nintendo 64 console that ran commercial games. Initial discussion about HLE occurred to give context for the reasons behind some video games not functioning properly with the emulator. The earliest (1962) high-level emulator was called a functional simulator for executing military flight programs written in symbolic assembly language code, without generating binary code.
Contents |
In order for HLE approach to work, the platform in question must meet certain criteria. Namely, there must exist a higher abstraction level than the raw binary machine code to be executed, realised directly in the hardware, or by the operating system. In any case, it must exist outside of the software intended to run on the emulated platform, and have certain amount of standardisation and semantics for HLE to succeed.
Compared to LLE, HLE has a very different set of design decisions and trade-offs. First, as the complexity of modern (fifth generation and above) video consoles rapidly increases, so does their computational power, and also the distance to the commodity PCs, which are the most common host systems for the emulators. Thus, the requirements on the quality of the emulated services increases, together with the difficulty of doing so. Hardware chips in consoles are usually extremely specialised towards specific functionality needed by games written for them, often in directions which are completely different than those taken by the hardware in an average PC machine. For example, 3D graphics might be realised by an extremely fast integer processor, coupled with the assumption of main system memory being the same as graphics memory, taking away the separate step of loading textures.
Emulating such an architecture programmatically on a PC, characterised by the emphasis put on floating-point operations, and specialised graphics hardware with memory separate from the system memory would be extremely difficult, especially taking into account the scarcity of documentation typical for specialised, proprietary hardware. Even if such emulator could be created, it would be much too slow for use. Instead, with HLE approach, the emulator would be rather written to take the data to be processed, along with the operations list, and implement it using the means available on the host systems, i.e. floating-point maths and GPU. The result is not only a much better match with the host platform, but often also significantly better results, as floating-point computation yields higher quality graphics suitable for high resolution displays available for PCs.
Among the advantages of HLE technique, chiefly are the ability to utilise the existing host facilities much better and easier, the ability to optimise the results as the code and hardware improves, and much less or no work at all needed to achieve the desired end result, if an appropriate function is already provided by the host, as would be common in 3D graphics functionality. The progress of implementations is also much more independent of the detailed hardware documentation, instead relying only on the listing of possible functions available to the programmer, which is already provided by a software development kit available for each platform.
The disadvantages include much higher reliance on standardisation among target applications, and the presence of sufficiently high-level mechanisms in the emulated platforms. If there is no such mechanism, or applications fail to utilise it in one of the already supported ways, they will not work correctly, even if other, superficially similar applications function with no problems. Thus a significant amount of tweaks might be required to get all of the desired titles to run satisfactorily.
As a side-effect, HLE removes the common source of legality issues, by not requiring the users to provide it with the bootstrap software used by the original platform to create an environment for applications to run in. Because the emulator itself provides such environment, it no longer needs system ROM images, bootstrap cartridge images or other software obtained from a physical copy of the emulated system, a process which usually resulted in an unclear status in the light of copyright law.
As the console systems progress into more and more complexity, the importance of HLE approach increases. Modern (6th and 7th generation) video consoles are already far too complex and powerful to facilitate their emulation using the traditional approach. Additionally, some systems (notably Xbox) are themselves little more than a standardised PC machine, making it wasteful to try to recreate the hardware using PC as the host machine. Thus, HLE increasingly becomes the only sensible approach.